home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Sprite 1984 - 1993
/
Sprite 1984 - 1993.iso
/
src
/
cmds
/
scvs
/
scvs.man
< prev
next >
Wrap
Text File
|
1991-10-28
|
15KB
|
336 lines
'\" Copyright 1991 Regents of the University of California
'\" Permission to use, copy, modify, and distribute this
'\" documentation for any purpose and without fee is hereby
'\" granted, provided that this notice appears in all copies.
'\" The University of California makes no representations about
'\" the suitability of this material for any purpose. It is
'\" provided "as is" without express or implied warranty.
'\"
'\" $Header: /sprite/lib/forms/RCS/cmd.man,v 1.3 91/01/07 17:52:58 mottsmth Exp $ SPRITE (Berkeley)
'/"
.so \*(]ltmac.sprite
.HS SCVS cmds
.BS
'\" Note: do not modify the .SH NAME line immediately below!
.SH NAME
scvs \- Sprite Concurrent Version System
.SH SYNOPSIS
\fBscvs\fP [\fIscvs_options\fP] [\fIcvs_options\fP] \fIcommand [command_options] [command_args]\fP
.SH OPTIONS
.IP "\fB\-V\fP" 15
Print out verbose status messages during processing.
.IP "\fB\-D\fP" 15
Print out debugging information.
.IP "\fB\-help\fP" 15
Print a summary of the command-line options and exit without updating
any targets.
.BE
.SH DESCRIPTION
.PP
\fBScvs\fP is a front end to the \fBcvs\fP source control system, which
in turn is turn a front end for \fBrcs\fP.
It would probably help to be familiar with both
\fBcvs\fP and \fBrcs\fP before dealing with \fBscvs\fP.
\fBScvs\fP has the following
features in addition to those of \fBcvs\fP and \fBrcs\fP:
.TP
\(bu
A configuration file is used to specify the root of the \fBcvs\fP repository,
rather than an environment variable or a command line option.
.TP
\(bu
\fBScvs\fP keeps track of who has copies of which modules. When you check out
a module \fBscvs\fP will tell you about other copies of the same
module you might have, and about other users that have copies of the module.
This allows users to coordinate their modifications to a module.
'\" .TP
'\" \(bu
'\" If the most recent version of a module is checked out then the corresponding
'\" object files are retrieved from the appropriate directory specified in the
'\" configuration file.
.TP
\(bu
Changes to several modules can be committed simultaneously.
.TP
\(bu
\fBScvs\fP remembers the options used to checkout a module, so that subsequent
updates of the module use the same options, thus guaranteeing that the
same version of the module is updated.
.TP
\(bu
\fBScvs\fP has limited support for symbolic links.
When a module is checked into the repository any symbolic links it
contains are stored in a file called \fISCVS/links\fP.
When a module is checked out its symbolic links are created from the
contents of \fISCVS/links\fP.
.SH COMMANDS
.PP
Each invocation of \fBscvs\fP must specify a particular command to be performed.
Most of these commands are slight variations on the corresponding \fBcvs\fP
commands.
.TP
\fBadd\fP [\fB\-m\fP '\fImessage\fP'] \fIfiles...\fP
Create a new file or directory in the repository. Files are not actually
added to the repository until a \fBcommit\fP command is issued. See the
\fBcvs\fP man page for more details.
.TP
\fBcheckout\fP [\fB\-QqlnfPi\fP] [\fB\-c\fP] [\fB\-r\fP \fItag\fP | \fB\-D\fP \fIdate\fP] \fImodules\fP...
Retrieves copies of the specified modules from the repository.
For each module a
subdirectory with the module's name
is made in the current directory and the module's source tree is put in
the subdirectory.
'\" If the most recent version of the module is checked out then the corresponding
'\" object files are also copied into the source tree, assuming that the
'\" object file directory is specified in the config file (see
'\" \fISCVS.config\fP in the
'\" \fBFILES\fP section below).
The default is to check out the most recent version of the module, although
a particular version can be checked out by using
either the \fB\-r\fP
or \fB\-D\fP options, which will check out a version matching the
given tag or date, respectively.
The semantics of the \fBscvs\fP checkout command differ from \fBcvs\fP's
in that empty directories are
pruned unless the \fB\-P\fP option is given.
Empty directories usually occur if you check out a version of a module
from before a directory was created.
The \fB\-Q\fP and \fB\-q\fP options cause varying degrees of quietness, and the
\fB\-l\fP option causes the command to not be recursive.
.SP
The \fBcheckout\fP command will tell you of other copies of the module that
you might have, and about other users that have copies of the module.
If you are checking out a version to go off on your own and make changes
that will never be checked back in, then you should use the \fI\-i\fP
option. You will not be listed as having an official copy of the module,
so other people will not be told that you have a copy. Everything else
works the same, however.
.SP
\fBco\fP can be used as an abbreviation for \fBcheckout\fP.
.TP
\fBcommit\fP [\fB\-fnl\fP] [\fB\-m\fP '\fIlog_message\fP'] [\fB\-r\fP \fIrevision\fP] [\fImodules...\fP] [\fIfiles...\fP]
The \fBcommit\fP
command is used to check in the changes made to your copies of modules.
If no modules are specified then the current directory is checked in.
\fBScvs\fP differs from \fBcvs\fP
in that multiple modules can be checked in simultaneously,
and that commit is recursive.
\fBScvs\fP
achieves this by locking all modules, verifying that they are up-to-date
with the sources in the repository, then committing the changes.
\fBScvs\fP will also update a snapshot or installed copy of the sources
as indicated in the \fISCVS.config\fP file (see \fBFILES\fP section below).
.SP
The \fB\-f\fP option allows you to commit files that do not contain the
RCS $Id or $Header keywords. The \fB\-r\fP sets the RCS version number,
and the \fB\-n\fP option causes any commit command in the module database
to not be run. If the \fB\-m\fP option is not specified than an editor
will be invoked to allow you to enter the log message.
.SP
\fBci\fP can be used as an abbreviation for \fBcommit\fP.
.TP
\fBdiff\fP [\fB\-lR\fP] [\fIrcsdiff_options\fP] [\fIfiles...\fP]
Same as for \fBcvs\fP. Runs \fBrcsdiff\fP on the specified files, or on
only those files that you have changed.
\fBDiff\fP is recursive unless the \fB\-l\fP option is specified.
If no options are given \fBdiff\fP will print out the differences between
your copy of the file and the copy you checked out, i.e. it prints
the changes you made to the file.
If the \fB\-R\fP option is given then the differences between your
copy of the file and the current version is given.
This is useful if your copy is out-of-date and you want to see what
changed.
See the \fBrcsdiff\fP man page for more details on the options.
.TP
\fBdone\fP [\fB\-d\fP] \fImodules...\fP
When you have finished with a module you should use the \fBdone\fP
command, so that \fBscvs\fP
can update its database of module copies.
If the \fB\-d\fP
option is given then your copy of the module will be deleted.
If your copy differs from the repository \fBscvs\fP
will ask you whether
or not you are really done.
Make sure you really, truly are done before running this command,
particularly with the \fB\-d\fP option.
.TP
\fBinfo\fP [\fB\-l\fP] [\fIfiles...\fP]
Prints out status information about your sources.
Output is the same as for the \fBupdate\fP command.
\fBInfo\fP is recursive unless the \fB\-l\fP option is given.
.TP
\fBjoin\fP [\fB\-Qqf\fP] [\fB\-r\fP \fItag\fP | \fB\-D\fP \fIdate\fP] \fIfiles...\fP
Same as for \fBcvs\fP. Used to merge in a new vendor release of a software
package.
See the \fBcvs\fP man page for details.
.TP
\fBlock\fP [\fB\-rw\fP] [\fImodules...\fP]
Each
\fBscvs\fP command
locks the module in the repository before mucking
around with it, thus preventing concurrent \fBscvs\fP commands from creating
chaos.
If you wish to run several \fBscvs\fP commands without allowing other users
to run commands inbetween you can use \fBlock\fP.
A common example is committing your changes to a module.
If you don't \fBlock\fP the module first
there are potential races between the time you update your sources and
the time you commit them, and between the time you commit them and
update the installed copy.
To prevent these races you should \fBlock\fP any modules you want to commit,
then run any \fBcommit\fP commands, verify that the installed sources
are correct, then \fBunlock\fP the modules.
The \fB\-w\fP
option
creates a write lock (the default), so that you have exclusive
access to the module.
The \fB\-r\fP
option creates a read lock, allowing other users to read the module
but not modify it.
See the \fBunlock\fP command below.
.TP
\fBlog\fP [\fB\-l\fP] [\fIrlog_options\fP] [\fIfiles...\fP]
Same as for \fBcvs\fP. Does an \fBrlog\fP on the specified files, or on
every file in the current directory.
\fBLog\fP is recursive unless the \fB\-l\fP option is specified.
See the \fBcvs\fP man page for details.
.TP
\fBpack\fP [\fB\-l\fP] [\fIdirs...\fP]
The pack command is used to put entries for all symbolic links in the
given directories (or the current directory) into the file \fISCVS/links\fP
(see \fBFILES\fP section below).
This file can then be used later by the \fBunpack\fP command to recreate
the symbolic links.
The \fBpack\fP command is run
implicitly during a \fBcommit\fP,
and is not usually invoked explicitly.
\fBPack\fP is recursive, unless
the \fB\-l\fP option is given.
.TP
\fBpatch\fP [\fB\-Qqlf\fP] [\fB\-s\fP|\fB\-t\fP] [\fB\-r\fP \fItag\fP|\fB\-D\fP \fIdate\fP [\fB\-r\fP \fItag\fP|\fB\-D\fP \fIdate\fP]] \fImodules...\fP
Same as for \fBcvs\fP.
Creates a \fBpatch\fP file between the two versions of the modules.
See the \fBcvs\fP man page for details.
.TP
\fBremove\fP \fIfiles...\fP
Same as for \fBcvs\fP.
Removes the specified files from the repository.
The files are not actually deleted until the current module is \fBcommit\fPted.
See the \fBcvs\fP man page for details.
.TP
\fBstatus\fP [\fB\-l\fP] [\fIfiles...\fP]
Same as for \fBcvs\fP.
Prints out the \fBrcs\fP version in your copy of the file
and the current \fBrcs\fP version of the file in the repository.
\fBStatus\fP is recursive unless the \fB\-l\fP option is specified.
See the \fBcvs\fP man page for details.
.TP
\fBtag\fP [\fB\-Qqlfn\fP] [\fB\-d\fP] [\fB\-r\fP \fItag\fP|\fB\-D\fP \fIdate\fP] \fIsymbolic_tag\fP \fImodules...\fP
Same as for \fBcvs\fP.
Assigns a symbolic tag name to the given (or current) version of the
sources in the repository.
See the \fBcvs\fP man page for details.
.TP
\fBunlock\fP [\fB\-a\fP] [\fImodules...\fP]
Removes any locks you have on the modules.
If the \fB\-a\fP option is given then all locks on the module are removed.
See the \fBlock\fP command above.
.TP
\fBunpack\fP [\fB\-l\fP] [\fIdirs...\fP]
Creates symbolic links in the specified directories (or the current directory)
from the contents of the SCVS.links file.
The \fBunpack\fP command is run
implicitly during a \fBcheckout\fP or \fBupdate\fP,
and is not usually invoked explicitly.
\fBUnpack\fP is recursive, unless
the \fB\-l\fP option is given.
.TP
\fBupdate\fP [\fB\-QqlfpB\fP] [\fB\-e \fIdir\fP] [\fB\-d\fP] [\fB\-r\fP \fItag\fP|\fB-D\fP \fIdate\fP] [\fImodules...\fP] [\fIfiles...\fP]
The update command is used to make your copies of modules up-to-date with
the sources in the repository.
The default behavior is to bring your copy up-to-date with the version
that was checked out, although this can be modified with the \fB\-r\fP
or \fB\-D\fP options.
You will have to specify these options to subsequent \fBupdate\fP commands
if you wish to continue to use a different version than the one that
was checked out.
\fBUpdate\fP is recursive by default, but this can be overridden by the
\fB\-l\fP option.
The \fB\-B\fP option will cause \fBupdate\fP to not update your sources
with any new directories in the repository. The default behavior is
to do so (this differs from \fBcvs\fP).
See the
\fBcvs\fP man page for more details on the algorithm used by \fBupdate\fP
and for an explanation of its output.
.TP
\fBwho\fP [\fImodules...\fP]
Prints out the names of users who have checked out copies of the modules.
.SH FILES
.TP
\fBSCVS.config\fP
When \fBscvs\fP is invoked it works its way up the directory tree looking for
the file \fBSCVS.config\fP.
The first one that is found is used. The \fBSCVS.config\fP
file has the following
format. A blank line or a line beginning with '#' is ignored. A line
beginning with \fBcvsroot:\fP specifies the pathname of the \fBcvs\fP root
directory.
'\" A line beginning with \fBobjdir:\fP specifies the pathname of a directory
'\" tree that contains a copy of the most recent version of the modules,
'\" along with their object files. The contents of this tree are used to populate
'\" user's copies of modules with the current object files.
The following is a sample SCVS.config
file for the Sprite kernel sources.
.SP
.sp
.in +1i
.ft C
.nf
cvsroot: /sprite/src/kernel/Cvsroot
installdir: /sprite/src/kernel
'\" objdir: /sprite/src/kernel
.fi
.ft P
.in -1i
.sp
.TP
\fBSCVS/args\fP
This file is created by the \fBcheckout\fP command, and is put in the
top-level subdirectory of a module copy. It contains the arguments
passed to the \fBcheckout\fP
command, so that subsequent \fBupdate\fP commands
use the correct version of the sources.
.TP
\fBSCVS/links\fP
The \fBSCVS/links\fP file contains information about symbolic links in the
module sources.
Each line is of the form "\fIlinkName\fP \fItarget\fP",
where \fIlinkName\fP is the name of the symbolic link to be created, and
\fItarget\fP is the file to which the link points.
\fBSCVS/links\fP is created by the \fBpack\fP and \fBcommit\fP commands,
and read by the \fBcheckout\fP and \fBupdate\fP commands.
Each subdirectory of a module has its own \fBSCVS/links\fP file.
.TP
\fBSCVS/users\fP
The \fBSCVS/users\fP file exists in each module in the repository and contains
information about the users who have the module checked out.
Each line is of the form: "\fIuser\fP \fIpath\fP \fIdate\fP",
where \fIuser\fP is the name of the user who has the module checked out,
\fIpath\fP is the pathname of their copy of the module,
and \fIdate\fP is the time
when the copy was checked out.
.TP
\fBSCVS/locks\fP
Exists in the module directory in the repository and contains a
list of locks on the module. Each line is of the form
"\fItype user date\fP", where \fItype\fP is one of \fIr\fP or \fIw\fP,
\fIuser\fP is the login name of the lock owner, and
\fIdate\fP is the time the lock was created.
.SH SEE ALSO
\fBrcs\fP(1), \fBci\fP(1), \fBco\fP(1), \fBrcsdiff\fP(1), \fBpatch\fP(1),
\fBrcsmerge\fP(1), \fBrlog\fP(1), \fBcvs\fP(1)
.SH KEYWORDS
source control, rcs, cvs